A configuration tracking system keeps track of changes to the configuration of assets such as computers, storage devices, network devices, and software packages. A configuration tracking system implements a service that allows clients of the service (users or other systems) to interact with the configuration system. The interactions may be to obtain the most recent configuration for an asset or a history of changes to the configuration of an asset.
In a traditional configuration tracking system implementation, there are usually at least two components. The first component is the agent that interacts with one or more assets to obtain asset data, such as asset component inventory and configuration information. The second component is the server that receives the asset data from the agent(s) and stores the asset data in one or more databases. The server also implements a service that is used by clients to access the asset information maintained by the configuration tracking system. Typically, the server stores asset information in a database. The database may be stored in a file system or directly on disk volumes.
The availability of a service, such as the configuration tracking service, is related to cost, complexity, and overhead of the service. The availability of the configuration tracking service is a key concern because IT organizations and organizations that provide IT services depend on this vital infrastructure. One mechanism to increase availability of a configuration tracking system is to implement data redundancy. Data redundancy refers to the process of maintaining more than one copy of data to increase availability by eliminating or reducing effects of data storage device failures.
The traditional approach to increasing availability of a configuration tracking system is through applying conventional clustering techniques to the server component for local failover, and applying remote database or storage replication techniques to the server database for disaster recovery (i.e., wide area failover). In both cases, the configuration tracking system relies on the underlying infrastructure, such as clustering software or underlying wide area replication technologies, to provide for data redundancy. This is known as “implicit data redundancy” because the configuration tracking system is not an active participant in maintaining data redundancy; instead, the data redundancy is a feature of the technology infrastructure and platform on which the configuration tracking system is deployed.
Implicit data redundancy is convenient because configuration tracking service implementations do not have to be directly concerned with data redundancy. They assume that data redundancy will be provided by lower level platform or technology components, and it is these lower level components that will determine data redundancy policies and operations. However, implicit data redundancy many times results in services being built around a notion of a single data instance. A single data instances means that a service operates with and understands only a single instance of data.
A key problem with this approach is the corruption of the single instance leading to inconsistencies and possible complete loss of data. Another problem with the notion of a single data instance is that either a service is available if its data is accessible (normal operation) or not available if its data is not accessible (no operation). There is no option for providing a degraded, yet available, service. This is known as the binary notion of availability.
Implicit data redundancy pushes the responsibility for data availability to the lower level infrastructure, deployment design, and operations. However, single data instance consistency can be very costly and difficult to implement, especially for disaster recovery purposes. In practice, there will be multiple instances of the data, but the service will only interact with a single instance at a time. Hence, implicit data redundancy does not eliminate the need to think about and address inconsistencies among multiple instances of data.